双链笔记已经不香了？号称 EverythingOS 的「节点标签」笔记来了 #猜猜是谁
写在前面
在介绍今天要讲的这款「新概念」笔记App 之前，请允许我先讲一下，火箭君自己的笔记。
目前，我已经将笔记全部迁移到了本地的 Obsidian 当中。Obsidian提供了非常实用的「双链」体系。Obsidian 的链接指向是一个个笔记（文件），这是链接的最小单位，一般来说够用了。
如果，像火箭君一样，喜欢将事情按大纲罗列的话，其实每个大纲的节点也是一个很重要的单位。下面是我用 Obsidian 的常规套路，内容纯属虚构（显然的）。
大家会注意到，按照层级节点，可以快速分解几乎所有的事情。另外我会习惯在节点后面加上「#标签」。Obsidian的「标签」机制其实一点也不比 「双链」逊色。通过标签，我们可以快速将一些文本聚合在一起， 例如在例子中，我们可以快速将所有笔记里面的 #meeting 聚合在一起审视。也可以查看所有标记沙漏的节点，这也就是基本的「待办清单」了。
所以，我们看到 节点+标签 对于火箭君这类「条理人」来说有重要意义。这点上 OB 已经做得非常不错，直到……
直到最近火箭君最近才拿到了 一款 新概念笔记 Tana 的邀请（很多油管大V两个月前就拿到邀请了），这才顿时有种「原来还能这样」的感觉。
接下去，我就介绍一下 新概念笔记 Tana 的上手体验。
Tana 登场
Tana 是一款很新的笔记 App，目前还在邀请测试阶段。Tana 号称是 EverythingOS，也被称为是「数据库笔记」，我觉得更像是 「节点标签」笔记。
Tana的野心在于：有潜力管理我们身边的任何事情，换言之，将所有事情高度结构化的组织起来。
某种意义上来讲，如果我们是一个「讲条理」的人，那么多半会被 Tana 立刻吸引。更具体一点来说， 如果我们常用 清单类工具， 喜欢幕布或Workflowy之类的大纲工具，喜欢 Roam Research和 LogSeq 之类节点笔记的话， 我们多半会被 Tana 吸引。
节点
Tana 的哲学很简单，所有的事情，都是一个个「节点」。这个所谓节点（node）就是各位大纲笔记里面的一个 point，也是清单 App 里面的一个 task，牵强一点，也是 row， 也是 line。
节点可以并列，可以互相嵌套，互相引用。节点嵌套，不是什么新鲜的概念。我们的文件夹树状结构，也可以看作是文件节点的呈现。所有信息都是文件（或文件夹），文件（文件夹）可以互相嵌套从属（严格来说，传统的文件结构有父子顺序，不能循环嵌套）。
所以，我们首先要意识到，Tana最革命性的地方在于打破了「笔记」必须是一篇文档的概念，笔记可以是一个节点，亦可是节点的组合（听听就 亦可赛艇）。可以是父子嵌套节点，也可以是并列的类似的节点或者某类节点的聚合。
比如：可能有一份节点笔记叫做 当日输入 （这是 Tana 默认的节点种类，可理解成 自带 Daily Log 视图），里面有 所有今天输入的内容节点，组成了一个笔记。
比如：一个名为 Launching to Mars 的项目，下面所有的子任务节点项目，组成了一个笔记
又比如：所有的 Project，又能 组成一个项目列表的笔记。
……
因此，节点才是Tana的基本单位，我们传统意义的笔记并不是 Tana 的基本单位， 而是 节点的视图。这是一种「全部打碎，再重新组合」的概念。
我们可以在任何节点下面，引用另一个节点，引用时通过 @开头，填写关键字检索， 类似双链笔记的 [[ 开头检索。但是， 值得注意的是，Tana 产生的不是传统的超链接，而是被引用节点本身，类似Notion 的「同步块」（Sync Block）。被引用节点内容可以被立刻呈现，立刻编辑。这个背后的逻辑还是， 笔记只是节点的一个组织视图， 节点就是节点，无论在哪个视图下，都是同一个节点。
超级标签
这个词 SuperTag， 貌似已经被Tana注册商标了， 可见Tana 对这个概念的重视程度。
当我们把信息打碎到「节点」级别的时候，势必要有一种高效聚合信息的手段。除了刚才说的「从属嵌套」（大纲）结构以外， 「标签」可能是最好的聚合手段。Bear 这类App 把标签运用在基于文档的笔记里面，构建一个标签分类体系，代替文件夹体系。而 Tana 更彻底，把标签运用到「更原子」的节点上。
这样一来，我们说的，所有 #会议记录， 所有的 #重要， #稍后再说， 都可以被 快速聚合起来， 再配合之前所看到的大纲结构，我们几乎立刻可以看到所有项目的大致信息和详细信息。
我曾经在 Todoist 组织自己的任务，按照层级，按照标签，但是很难做好。按照标签时会丢失层级，按照层级又无法按照标签聚合。而Tana 的「标签」从根本上彻底的解决了这类问题。
数据库笔记
这也是外界给 Tana 的一个常用称号，Tana 把 数据库查询语言的接口暴露给了用户。如果用户有一定的组织和逻辑能力，可以构造自己的数据查询视图。对于很多用户来说，这点可能要求比较高，但是对于专业用话来说，可能如鱼得水（DB工程师狂喜）。
例如：我们可以自己组织出，所有「#企业级」标签下，关于「#李姐」的，而且提到「元宇宙」字样的笔记视图。
这个功能，我们先就此按住，按照节点笔记的思路走下去，Tana 后续可以玩出很多数据库级别的用法。以后可能要看着参考手册才能玩下去（《MySQL 从入门到删库跑路》这类手册）。
另一个角度来说， 当我们提到Notion 表现出色的 Database 功能时， 很多时候我们是赞叹于：Notion 对检索结果的多种视图展现。例如：清单，表格，卡片，画廊 …… 这些 Notion Databse 的 优点，也被 Tana 吸收了。Tana 可以用多种形式展现节点结果。所以以前有人和我反复说（有抬杠嫌疑）：Notion不是笔记是数据库时，我那时觉得 Notion 最多就是 伪装成数据库的笔记。其实，Tana 才是真正的 伪装成笔记的数据库。
十动然拒
火箭君之前在一款合作小伙伴的笔记产品中建议过 将笔记内容打碎 重新按照 标签和筛选条件组成 新的 「智能文档」。这个功能的原型，小伙伴也已经做出来了，但是产品本身未能大规模面世，非常遗憾。而 Tana 的出现，很大程度上实现了我个人的一个夙愿。
尽管我十分感动，但我还是要 「一票拒绝」Tana。不是因为它不优秀，不是因为它理念不够先进，而是因为它是一个「云存储」的在线笔记。我不是绝对排斥云产品，云产品在我这里只能是一个中间环节，最终的笔记归档，一定要落在我的本地，这也是我选择 Obsidian的原因之一。尤其到了今天，我们应该愈发清醒的认识到，「信息的所有权」是我们在数字世界里，非常重要且少数可以自己掌握的权利。
Tana 如此优秀，结构层级标签一应俱全，是一个理想的「归档体系」。但是，即使内容可以导出到本地，结构层级很可能无法导出到本地，或者说，一旦导出，就会丧失那些节点数据库的优势，除非本地有个数据库。一考虑到这些，理智的选择就是，不要在一开始就投入太多，防止最后出现「割爱」的痛苦。
通俗来说， Tana 是个好人，但我不配（声明：我不是渣男）。
另一点来说，我觉得大家有必要正视这个可能， 一个 （开源的或不开源的）Tana-like 的本地版本或许是一个潜在的机会。这个本地化的 类Tana App 也许满足不了投资人对 团队协同，AI，数据挖掘的想象， 但确确实实是我们每个个人的福祉所在。在这之前， Obsidian，LogSeq 都会是很好的选择。
最后
如果各位想尝试 Tana， 需要到官网去，注册等待列表，并等待官方邀请。
总的来说，如果各位答应我 不过度沉溺于 Tana， 不把一切笔记交付给 Tana 归档的话，我就把 Tana 的官网地址告诉大家。Tana 还是非常非常值得各位体验一下的笔记工具。
目前 Tana 还是免费试用， 不过根据内部消息，很快将会根据用户的用量进行收费（这也合理）。
另外，提醒一下，Tana 官网上声称的部分功能，还未完全开放。我觉得，数据层面已经完全准备好了，剩下的只是个实现的时间问题。大家看看即可。
Tana 官网
https://tana.inc/